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USE OF CERTIFIED SECRETS IN COMMUNICATION 

Field of Invention 

5 The present invention relates to provision (and revocation) of certified secrets and 
commimication using such secrets, in particular communication that can indicate that 
one party possesses a secret formed in a particular way without revealing the secret 
itself The present invention is particularly relevant to trusted computing (for example 
of the type discussed by the Trusted Computing Group), in which one party has some 
10 assurance that a second party will behave in an expected manner. 

Discussion of Prior Art 

15 A recent development is the provision of computing apparatus that is "trusted" - that 
is, it can be relied on by the user to behave in a predictable manner and that 
. subversion by another will at the least be apparent. In the Trusted Computing 
Groupspecification (foimd at www.trustedcomputing.org) and in the associated book 
"Trusted Computing Platforms: TCPA Technology in Context", edited by Siani 

20 Pearson and pubhshed July 2002 by Prentice Hall PTR (the contents of which are 
incorporated by reference herein to the extent permissible by law), there is described 
an approach to trusted computing which employs a trusted coprocessor (both 
physically and logically protected from subversion) to assure a user of computing 
apparatus including or associated with the trusted coprocessor that it is performing in 

25 a predictable and unsubverted manner. A particularly useful arrangement, particularly 
where it is desirable to provide information and services for other computers, is to use 
both a compartmentalised operating system (typically by operating in a 
compartmentalised manner such that processes run in separated computing 
envirormients that have strictly controlled interaction with other computing 

30 environments) and trusted computing hardware using a trusted component (such an 
arrangement is discussed in, for example, the applicants' patent application published 
as EPl 182557). 



1 
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One advantage of using a trasted platform is that other parties will be ready to interact 
with the trusted platform as they have a means of assuring that it will behave in an 
expected manner. Such an other party may be a Remote Service Provider (RSP) who 
is able to provide a service to a platform, but may be unwilling to provide this service 
5 if it caimot be assured that the platform receiving the service is indeed trusted. It can 
be assumed that the RSP will trust at least some manufacturers of trusted components 
(trusted components are described here as Trusted Platform Modules or TPMs), which 
leaves tihte difficulty for the RSP being to ensure that TPMs interacting with the RSP 
have indeed been produced by a trusted manufacturer. There is a further 
10 consideration — it is desirable for privacy reasons for the RSP to be unable to 
distinguish which TPM it is interacting with (ie, desirably all that the RSP will be able 
to establish is that it is interacting with a bona fide TPM manufactured by a known - 
and trusted - manufacturer). 

15 The current approach to providing such an assurance to an RSP is to use a fiirther 
third party, a Certificate Authority (CA), trusted by both the platform's owner and the 
RSP. The TPM manufacturer provides a unique endorsement key for the TPM and 
then certifies it. The CA then issues a certificate on a randomly chosen identity after 
verifying the manufacturer's certificate. The CA may or may not maintain a Ust of the 

20 mapping between endorsement keys and corresponding certificates. It is then the 
CA's certificate that is used by the RSP to check the validity of the TPM - if the 
certificate is verified, the RSP will trust the TPM to be a legitimate product of the 
trusted manufacturer because the RSP trusts the CA. If the RSP finds out something 
wrong with a particular certificated identity, the RSP reports this to the CA and the 

25 CA puts the problem identity in a revocation list and then refiises to certify any new 
identity to this TPM. 

A difficulty with this scheme is that the CA is now a weak point in the system - it 
potentially possesses a mapping between a TPM's Endorsement Key and identities 
30 issued to that TPM (and probably that of a large number of TPMs). If the CA reneges 
on a promise not to maintain such a mapping, or if the CA is permitted to keep such 
mappings as long as they are confidential but the CA's database is compromised, it 
becomes possible to correlate the identites of all TPMs which have been certified by 
that CA. 
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It is therefore desirable for a TPM to be able to assure an RSP that it is the legitimate 
product of a trusted manufacturer without trusting a third party such as a CA with 
attestation information given by a manufacturer to the TPM. It is also desirable for 
5 this to be done in such a way that the status of the TPM can be revoked without 
allowing RSPs to become aware of the attestation information given by a 
manufacturer to the TPM that it is interacting with at any given time. 

It can be appreciated that these problems can have broader application to 
10 communication between parties than the specific problem identified here in relation to 
trusted computing platforms — for example, the problem can apply whenever similar 
tmst relationships exist in relation to a secret between a possessor of the secret, a 
guarantor of the secret, and a party relying on the validity of the secret. 

15 

Summarv of Invention 

Accordingly in a first aspect, the invention provides method of determining access to 
computational resources by means of a group signature scheme with revocation 

20 evidence, the method comprising: a certificate issuer holding a group secret key and 
providing a group public key; a group member obtaining a membership secret and the 
certificate issuer providing a membership certificate for a group member in respect of 
the membership secret; the group member demonstrating that it possesses a valid 
membership secret and a valid membership certificate to a verifier without revealing 

25 the membership secret or the membership certificate to the verifier by providing a 
signature, and providing revocation evidence firom its membership secret and a 
revocation parameter; the verifier determining from the signature and from the 
revocation evidence that the group member possesses a valid membership secret and a 
valid membership certificate. 

30 

In a further aspect, the invention provides a method of demonstrating a trust status by 
a member of a group signature scheme which has a group public key, the method 
comprising: the group member obtaining a membership secret and receiving from a 
certificate issuer a membership certificate for a group member in respect of the 
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membership secret; the group member demonstrating that it possesses a valid 
membership secret and a vaUd membership certificate to a verifier without revealing 
the membership secret or the membership certificate to the verifier by providing a 
signature, and providing revocation evidence firom its membership secret and a 
5 revocation parameter. 

In a further aspect, the invention provides a method of verifying a trust status of a 
member of a group signature scheme which has a group public key, the method 
comprising: the verifier receives firom a group member a signature generated firom a 
10 membership secret and a membership certificate of the group member, and receives 
revocation evidence provided by the group member from its membership secret and a 
revocation parameter; and the verifier determining from the signature and from the 
revocation evidence that the group member possesses a valid membership secret and a 
valid membership certificate. 

15 

In a further aspect, the invention provides a trusted computing apparatus comprising a 
processor and a memory containing a membership secret and a membership certificate 
issued on the membership secret by a certificate issuer for a group signature scheme 
having a group public key, the trusted computing apparatus being adapted to 
20 demonstrate that it possesses a vaUd membership secret and a valid membership 
certificate to a verifier without revealing the membership secret or the membership 
certificate to the verifier by providing a signature, and to provide revocation evidence 
from its membership secret, its membership certificate, the group public key and a 
revocation parameter. 

25 

In a further aspect, the invention provides a method by which a first party can prove 
to a second party that it possesses a secret legitimately provided by a third party, 
comprising the steps of: 

the third party providing to the first party a first secret w, and a second secret c 
30 calculated according to the relation c = if\nf^ + tif"^ mod n from the first secret, where 
n is a RSA modulus, e\ and are RSA public exponents, and and are randomly 
chosen integers, whereby d\ is an RSA private exponent corresponding to ei, 

the second party obtaining from the third party /z, e^^ t\ and t2\ 
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in order to prove to the second party that it has a first secret m and a second 
secret c formed according to the relation, the first party provides the second party with 
a first plurality of results of a one-way function using the first secret and a second 
plurality of results of a one-way function using the second secret; 
5 whereby the second party compares the first plurality of results with results of a one- 
way function using e\ and the second plurality of results with results of a one-way 
function using ez, and thereby verifying that the second party has a first secret m and a 
second secret c formed according to the relation without receiving either the first 
secret m or the second secret c. 

10 

In a related aspect, the invention provides trusted computing apparatus comprising a 
processor and a memory containing a first secret m, and a second secret c calculated 
according to the relation c = (^im^' + /2)'^' mod n from the first secret, where n is a RSA 
modulus, e\ and €2 are RSA public exponents, and t\ and t2 are randomly chosen 

15 integers, whereby d\ is an RSA private exponent corresponding to ei,wherein the 
processor is programmed to prove to an other party that it possesses a first secret m 
and a second secret c formed according to the relation without revealing either the * 
first secret m or the second secret c, by providing the other party with a first plurality 
of results of a one-way function using the first secret and a second plurality of results 

20 of a one-way fimction using the second secret. 

In a further aspect, the invention provides a method of controlling access of a first 
party to a service provided by a second party, wherein the first party is adapted to 
prove to another party that it possesses a secret legitimately provided by a third party 
25 without revealing the secret, comprising the steps of: 

the first party proving and the fourth party verifying that the first party 
possesses a secret legitimately provided by the third party without the secret being 
revealed to the fourth party, 

the fourth party issviing a certificate to the first party and associating with the 
30 certificate an identifier of the step of verifying that the first party possesses a secret 
legitimately provided by the third party that would be regenerated in a later step of 
verifying that a party possesses that secret, 

the fourth party maintains certificate validity information, whereby when the 
first party attempts to obtain access to the service, it provides the certificate issued by 

5 
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the fourth party to the second party, and the second party determines from certificate 
vahdity information provided by the fourth party whether the certificate is vaUd 
before providing access to the service. 

5 Preferably, a group member is a computing apparatus and the certificate issuer is a 
manufacturer of the computing apparatus. More specifically, the computing apparatus 
is preferably a tmsted computing module adapted to be physically and logically 
resistant to unauthorised modification, and preferably adapted for use as a coprocessor 
of a computing platform. 

10 

Brief Description of Drawings 

For a better understanding of the invention and to show how the same may be carried 
15 into effect, there will now be described by way of example only, specific 
embodiments, methods and processes according to the present invention with 
reference to the accompanying drawings in which: 

Figure 1 is a diagram that illustrates schematically a system capable of implementing 
embodiments of the present invention; 
20 Figure 2 is a diagram which illustrates a motherboard including a trusted device 
arranged to communicate with a smart card via a smart card reader and with a group 
of modules; 

Figure 3 is a diagram that illustrates the trusted device of Figure 2 in more detail; 

Figure 4 illustrates the elements of a computer system suitable for carrying out 
25 embodiments of the invention; 

Figure 5 is a flow diagram which illustrates the steps involved in establishing 

communications between a trusted computing platform and a remote platform 

including the trusted platform verifying its integrity in accordance with conventional 

trusted platform technology; 
30 Figure 6 shows schematically trust relationships for conventional tmsted computing 

technology; 

Figure 7 shows schematically trust relationships employed in tmsted computing 
technology according to embodiments of the present invention; 
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Figure 8 shows schematically parties involved in a trusted computing technology 
architecture in accordance w^ith embodiments of the present invention together with 
interactions between these parties according to a group signature scheme; and 
Figure 9 shows a modification to the arrangement of Figure 8 which does not employ 
5 a revocation agency. 



Detailed Description of Specific Embodiments 

10 A trusted platform of the type discussed in flie Tmsted Computing Platform Alliance 
specification will now be described. Such platforms are described in earlier 
applications by the present applicants, in particular, hitemational Patent Application 
PubUcation Nos. WOOO/48063 and WOOO/54126 which are incorporated by reference 
herein to the greatest extent possible under applicable law. The elements of an 

15 exemplary trusted platform and its operation will first be described — the elements and 
operation of a second embodiment of the invention will then be described with 
reference to the preceding general discussion of trusted platforms. 

In this specification, the term "tmsted" when used in relation to a physical or logical 
20 component, is used to mean that the physical or logical component always behaves in 
an expected maimer. The behavior of that component is predictable and known. 
Trasted components have a high degree of resistance to xmauthorized modification. 

In this specification, the term "computer platform" is used to refer to a computer 
25 system comprising at least one data processor and at least one data storage means, 
usually but not essentially with associated communications facilities e.g. a plurality of 
drivers, associated applications and data files, and which may be capable of 
interacting with external entities e.g. a user or another computer platform, for example 
by means of connection to the internet, connection to an external network, or by 
30 having an input port capable of receiving data stored on a data storage medium, e.g. a 
CD ROM, floppy disk, ribbon tape or the like. The term "computer platform" 
encompasses the main data processing and storage facility of a computer entity. 
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By use of a trasted component in each computer entity, there is enabled a level of trust 
between different computing platforms. It is possible to query such a platform about 
its state, and to compare it to a trusted state, either remotely, or through a monitor on 
the computer entity. The information gathered by such a query is provided by the 
5 computing entity's tmsted component which monitors the various parameters of the 
platform. Information provided by the tmsted component can be authenticated by 
cryptographic authentication, and can be tmsted. A "tmsted platform" can thus be 
achieved by the incorporation into a computing platform of a physical tmsted device 
whose function is to bind the identity of the platform to reliably measured data that 
10 provides an integrity metric of the platform. The identity and the integrity metric are 
compared with expected values provided by a trasted party (TP) that is prepared to 
vouch for the trustworthiness of the platform. If there is a match, the implication is 
that at least part of the platform is operating correctly, depending on the scope of the 
integrity metric. 

15 

The presence of the tmsted component makes it possible for a piece of third party 
software, either remote or local to the computing entity to conmiimicate with the 
computing entity in order to obtain proof of its authenticity and identity and to 
retrieve measured integrity metrics of that computing entity. For a human user to gain 

20 a level of tmstworthy interaction with his or her computing entity, or any other 
computing entity which that person may interact with by means of a user interface, a 
trasted token device is used by a user to interrogate a computing entity's trasted 
component and to report to the user on the state of the computing entity, as verified by 
the trasted component. Authentication between the trasted component and the trasted 

25 token device is, in practical situations of interest, mutual — the user is authenticated by 
the trasted component, and (if the user has appropriate privileges) may be allowed to 
control it, and the trasted component is authenticated by the user (and recognised as a 
trasted component, and in appropriate circumstances a trasted component owned or 
controllable by the user). 

30 

The advantages and use in applications of a trasted platform of this type are discussed 
in some detail in International Patent Application Publication Nos. WOOO/48063 and 
WOOO/54126 and in considerable detail in "Trasted Computing Platforms: TCPA 
Technology in Context", and will not be described further here. 
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The trusted component in such an arrangement uses cryptographic processes. A most 
desirable implementation would be to make the trusted component tamper-proof, to 
protect secrets by making them inaccessible to other platform functions and provide 
5 an environment that is substantially immune to unauthorised modification. Since 
complete tamper-proofing is impossible, the best approximation is a trusted device 
that is tamper-resistant, or tamper-detecting. The trusted device, therefore, preferably 
consists of one physical component that is tamper-resistant. Techniques of tamper- 
resistance are well known to the skilled person, and are discussed fiirther in 
10 hitemational Patent Application Pubhcation Nos. WOOO/48063 and WOOO/54126 

A trusted platform 10, 40 is illustrated schematically in the diagram in Figure 1 (and 
graphically in Figure 4). The platform 10, 40 includes the standard features of a 
keyboard 14, 45, mouse 16 (not shown in Figure 4) and monitor 18, 44, which 
provide the physical 'user interface' of the platform. This embodiment of a trusted 
platform also contains a smart card reader 12, 42. Alongside the smart card reader 12, 
42 there is illustrated a smart card 19, 41 to allow tmsted user interaction with the 
trusted platform. In the platform 10, 40 there are (shown in Figure 1) a plurality of 
modules 15: these are other functional elements of the trusted platform of essentially 
any kind appropriate to that platform. The functional significance of such elements is 
not relevant to the present invention and will not be discussed further herein. 
Additional components of the trusted computer entity will typically include one or 
more local area network (LAN) ports, one or more modem ports, and one or more 
power supplies, cooling fans and the like, ha Figure 4 the computing platform 40 is 
shown connected to a network 43 (which could be a LAN, a network such as the 
public internet accessed by a modem, or any other form of network with appropriate 
connection), as is clearly relevant to the embodiments of the invention described 
below. 

30 As illustrated in Figure 2, the motherboard 20 of the trusted computing platform 10 
includes (among other standard components) a main processor 21, main memory 22, a 
trusted device 24 (the physical form of the trusted component described above), a data 
bus 26 and respective control lines 27 and lines 28, BIOS memory 29 containing the 
BIOS program for the platform 10 and an Input/Output (lO) device 23, which controls 

9 
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interaction between the components of the motherboard and the smart card reader 12, 
the keyboard 14, the mouse 16 and the monitor 18 (and any additional peripheral 
devices such as a modem, printer, scanner or the like). The main memory 22 is 
typically random access memory (RAM). In operation, the platform 10 loads the 
5 operating system (and the processes or applications that may be executed by the 
platform), for example Windows XP™, into RAM from hard disk (not shown). 

The computer entity can be considered to have a logical, as well as a physical, 
architecture. The logical architecture has a same basic division between the computer 

10 platform, and the trusted component, as is present with the physical architecture 
described in Figs. 1 to 3 herein. That is to say, the trusted component is logically 
distinct from the computer platform to which it is physically related. The computer 
entity comprises a user space being a logical space which is physically resident on the 
computer platform (the first processor and first data storage means) and a trusted 

15 component space being a logical space which is physically resident on the trusted 
component. In the user space are one or a plurality of drivers, one or a plurality of 
applications programs, a file storage area; smart card reader; smart card interface; and 
a software agent which can perform operations in the user space and report back to 
trusted component. The trusted component space is a logical area based upon and 

20 physically resident in the trusted component, supported by the second data processor 
and second memory area of the trusted component. Monitor 18 receives images 
directly from the trusted component space. Extemal to the computer entity are 
external commimications networks e.g. the Intemet, and various local area netvvorks, 
wide area networks which are connected to the user space via the drivers (which may 

25 include one or more modem ports). An extemal user smart card inputs into smart card 
reader in the user space. 

Typically, in a personal computer the BIOS program is located in a special reserved 
memory area, the upper 64K of the first megabyte of the system memory (addresses 
30 F000h to FFFFh), and the main processor is arranged to look at this memory 
location first, in accordance with an industry wide standard. 

The significant difference between the platform and a conventional platform is that, 
after reset, the main processor is initially controlled by the trusted device, which then 
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hands control over to the platform-specific BIOS program, which in turn initiaUses all 
input/output devices as normal. After the BIOS program has executed, control is 
handed over as normal by the BIOS program to an operating system program, such as 
Windows XP (TM), which is typically loaded into main memory 22 from a hard disk 
5 drive (not shown). 

Clearly, this change firom the normal procedure requires a modification to the 
implementation of the industry standard, whereby the main processor 21 is directed to 
address the trusted device 24 to receive its first instructions. This change may be 
10 made simply by hard-coding a different address into the main processor 21. 

Altematively, the trusted device 24 may be assigned the standard BIOS program 
address, in which case there is no need to modify the main processor configuration. 

A relatively secure platform can however be achieved without such a fixndamental 
15 change. In such implementations, the platform is still controlled by the BIOS at 
switch-on, so the BIOS (or at least the BIOS boot block) must also be trasted. This 
means that there will not be a single root-of-trust (as in the preferred trusted platform 
embodiment described) but two - the BIOS boot block will also be a root of trust. 

20 It is highly desirable for the BIOS boot block to be contained within the trusted device 
24. This prevents subversion of the obtaining of the integrity metric (which could 
otherwise occur if rogue software processes are present) and prevents rogue software 
processes creating a situation in which the BIOS (even if correct) fails to build the 
proper environment for the operating system. 

25 

The trusted device 24 comprises a number of blocks, as illustrated ia Figure 3. After 
system reset, the trusted device 24 performs an authenticated boot process to ensure 
that the operating system of the platform 10 (including the system clock and the 
display on the monitor) is running properly and in a secure manner - more accurately, 
30 to ensure that the state of the platform is reUably recorded. During the authenticated 
boot process, the trusted device 24 acquires an integrity metric of the computing 
platform 10. The trasted device 24 can also perform secure data transfer and, for 
example, authentication between it and a smart card via encryption/decryption and 
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signature/verification. The trusted device 24 can also securely enforce various 
security control policies, such as locking of the user interface. 



Specifically, the trusted device comprises: a controller 30 programmed to control the 
overall operation of the trusted device 24, and interact with the other functions on the 
trusted device 24 and with the other devices on the motherboard 20; a measurement 
function 31 for acquiring tiie integrity metric from the platform 10; a cryptographic 
function 32 for signing, encrypting or decrypting specified data; an authentication 
function 33 for authenticating a smart card; and interface circuitry 34 having 
appropriate ports (36, 37 & 38) for connecting the trusted device 24 respectively to 
the data bus 26, control lines 27 and address lines 28 of the motherboard 20. Each of 
the blocks in the trusted device 24 has access (typically via the controller 30) to 
appropriate volatile memory areas 4 and/or non-volatile memory areas 3 of the tmsted 
device 24. Additionally, the trusted device 24 is designed, in a known manner, to be 
tamper resistant. 

In a preferred arrangement, the monitor 18 may be driven directly by a monitor 
subsystem contained within the trusted component itself. In this embodiment, in the 
tmsted component space are resident the tmsted component itself, and displays 
generated by the tmsted component on monitor 18. This arrangement is described 
further in the applicant's International Patent Application Publication No. 
WOOO/73879, which is incorporated by reference herein. 

For reasons of performance, the tmsted device 24 may be implemented as an 
application specific integrated circuit (ASIC). However, for flexibility, the trasted 
device 24 is preferably an appropriately programmed micro-controller. Both ASICs 
and micro-controllers are well known in the art of microelectronics and will not be 
considered herein in any further detail. 

One item of data stored in the non-volatile memory 3 of the trusted device 24 is a 
certificate 350. The certificate 350 contains at least a public key 351 of the tmsted 
device 24 and an authenticated value 352 of a platform integrity metric measured by a 
tmsted party (TP). The certificate 350 is signed by the TP using the TP's private key 
prior to it being stored in the tmsted device 24. In later communications sessions, a 
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user of the platform 10 can verify the integrity of the platform 10 by comparing the 
acquired integrity metric with the authentic integrity metric 352. If there is a match, 
the user can be confident that the platform 10 has not been subverted. Knowledge of 
the TP's generally-available public key enables simple verification of the certificate 
5 350. The non-volatile memory 35 also contains an identity (ID) label 353. The ID 
label 353 is a conventional ID label, for example a serial number, that is unique within 
some context. The ID label 353 is generally used for indexing and labelling of data 
relevant to the trusted device 24, but is insufficient in itself to prove the identity of the 
platform 10 under trasted conditions. 

10 

The trusted device 24 is equipped with at least one method of reliably measuring or 
acquiring the integrity metric of the computing platform 10 with which it is 
associated. This gives a potential user of the platform 10 a high level of confidence 
that the platform 10 has not been subverted at a hardware, or BIOS program, level. 
15 Other known processes, for example vims checkers, will typically be in place to check 
that the operating system aad application program code has not been subverted. 

The measurement fimction 31 has access to: non-volatile memory 3 for storing a hash 
program 354 and a private key 355 of the trusted device 24, and volatile memory 4 for 
20 storing acquired integrity metric in the form of a digest 361. In appropriate 
embodiments, the volatile memory 4 may also be used to store the public keys and 
associated ID labels 360a-360n of one or more authentic smart cards 19 that can be 
used to gain access to the platform 10. 

25 Acquisition of an integrity metric is not material to the present invention, and is not 
discussed further here — this process, and the process of verifying the integrity of a 
trusted platform by a user or a third party, are processes discussed in detail in 
Intemational Patent Application Publication No. WOOO/48063. 

30 As indicated above, a preferred means for authenticating a user to a tmsted platform is 
a token device, such as a smart card 19 (though it should be noted that a user could, 
for example, be a remote platform conmnmicating with the trusted platform over a 
network). The user's smart card 19 is a token device, separate firom the computing 
entity, which interacts with the computing entity via the smart card reader port 19. A 
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user may have several different smart cards issued by several different vendors or 
service providers, and may gain access to the intemet or a plurality of network 
computers from any one of a plurality of computing entities as described herein, 
which are provided with a trusted component and smart card reader. A user's trast in 
5 the individual computing entity to which s/he is using is derived from the interaction 
between the user's trusted smart card token and the trusted component of the 
computing entity. Tlae user relies on their trusted smart card token to verify the 
trustworthiness of the trusted component. 

10 Figure 5 illustrates the flow of actions by a Tmsted Party TP, the trusted device 24 
incorporated into a platform, and a user (of a remote platform) who wants to verify 
the integrity of the trusted platform in accordance with prior art trusted platform 
technology. It will be appreciated that substantially the same steps as are depicted in 
Figure 5 are involved when the user is a local user. Li either case, the user would 

15 typically rely on some form of software application to enact the verification. It would 
be possible to run the software application on the remote platform or the trasted 
platform. However, there is a chance that, even on the remote platform, the software 
application could be subverted in some way. Therefore, it is preferred that, for a high 
level of integrity, the software application would reside on a smart card of the user, 

20 who would insert the smart card into an appropriate reader for the purposes of 
verification. 

At the first instance, a TP, which vouches for trusted platforms, will inspect the type 
of the platform to decide whether to vouch for it or not. This will be a matter of 

25 policy. If all is well, in step 500, the TP measures the value of integrity metric of the 
platform. Then, the TP generates a certificate, in step 505, for the platform. The 
certificate is generated by the TP by appending the tmsted device's public key, and 
optionally its ID label, to the measured integrity metric, and signing the string with 
the TP's private key. It should be noted that the present invention is particularly 

30 relevant to improvement to this chain of events and to the role of such a Tmsted Party 
(typically a Certificate Authority). 

The trasted device 24 can subsequently prove its identity by using its private key to 
process some input data received from the user and produce output data, such that the 
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input/output pair is statistically impossible to produce without knowledge of the 
private key. Hence, knowledge of the private key forms the basis of identity in this 
case. Clearly, it would be feasible to use symmetric encryption to form the basis of 
identity. However, the disadvantage of using symmetric encryption is that the user 
5 would need to share his secret with the trusted device. Further, as a result of the need 
to share the secret with the user, while symmetric encryption would in principle be 
sufficient to prove identity to the user, it would insufficient to prove identity to a third 
party, who could not be entirely sure the verification originated firom the trusted 
device or the user. 

10 

In step 510, the trusted device 24 is initialised by writing the certificate 350 into the 
appropriate non-volatile memory locations 3 of the trusted device 24. This is done, 
preferably, by secure commimication with the trusted device 24 after it is installed in 
the motherboard 20. The method of writing the certificate to the trusted device 24 is 
15 analogous to the method used to initiahse smart cards by writing private keys thereto. 
The secure communications is supported by a 'master key% known only to the TP, 
that is written to the trusted device (or smart card) during manufacture, and used to 
enable the writing of data to the trusted device 24; Avriting of data to the trusted device 
24 without knowledge of the master key is not possible. 

20 

At some later point during operation of the platform, for example when it is switched 
on or reset, in step 515, the trusted device 24 acquires and stores the integrity metric 
3 6 1 of the platform. 

25 When a user wishes to communicate with the platform, in step 520, he creates a 
nonce, such as a random number, and, in step 525, challenges the trusted device 24 
(the operating system of the platform, or an appropriate software application, is 
arranged to recognise the challenge and pass it to the trusted device 24, typically via a 
BIOS-type call, in an appropriate fashion). The nonce is used to protect the user from 

30 deception caused by replay of old but genuine signatures (called a 'replay attack') by 
untrustworthy platforms. The process of providing a nonce and verifying the response 
is an example of the well-known 'challenge/response' process. 
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In step 530, the trasted device 24 receives the challenge and creates an appropriate 
response. This may be a digest of the measured integrity metric and the nonce, and 
optionally its ID label. Then, in step 535, the trusted device 24 signs the digest, using 
its private key, and returns the signed digest, accompanied by the certificate 350, to 
5 the user. 

In step 540, the user receives the challenge response and verifies the certificate using 
the well known public key of the TP. The user then, in step 550, extracts the trusted 
device's 24 public key from the certificate and uses it to decrypt the signed digest 

10 from the challenge response. Then, in step 560, the user verifies the nonce inside the 
challenge response. Next, in step 570, the user compares the computed integrity 
metric, which it extracts from the challenge response, with the proper platform 
integrity metric, which it extracts from the certificate. If any of the foregoing 
verification steps fails, in steps 545, 555, 565 or 575, the whole process ends in step 

15 580 with no further communications taking place. 

Assuming all is well, in steps 585 and 590, the user and the trusted platform use other 
protocols to set up secure communications for other data, where the data firom the 
platform is preferably signed by the trusted device 24. 

20 

Further refinements of this verification process are possible. It is desirable that the 
challenger becomes aware, through the challenge, both of the value of the platform 
integrity metric and also of the method by which it was obtained. Both these pieces of 
information are desirable to allow the challenger to make a proper decision about the 
25 integrity of the platfonn. The challenger also has many different options available - it 
may accept that the integrity metric is recognised as valid in the trusted device 24, or 
may altematively only accept that the platform has the relevant level of integrity if the 
value of the integrity metric is equal to a value held by the challenger (or may hold 
there to be different levels of trust in these two cases). 

30 

The techniques of signing, using certificates, and challenge/response, and using them 
to prove identity, are well known to those skilled in the art of security and therefore 
need not be described in any more detail herein. 
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Specific embodiments of the invention will now be described which use and, in some 
cases, modify, the structures and protocols indicated above. Firstly, the situation of 
particular concern will be described with reference to Figure 6, which illustrates 
schematically the different parties involved or potentially involved in the procurement 
5 of a service by a trusted platform from a remote service provider (RSP) and their trust 
relationships in conventional trusted computing technology. 

• The trusted platform manufacturer 61 manufactures the trusted platform module 
(TPM) 62 and provides it Avith a unique endorsement key, which the manufacturer 

10 certifies (step 65). This certificated endorsement key is then passed (step 66) to a 
Certificate Authority (CA) 63 trusted by the trusted platform manufacturer 61 and a 
certificate is issued on a randomly chosen identity, which becomes a new identity for 
the TPM, by the CA (step 67). Li subsequent interaction with a Remote Service 
Provider (RSP) 64 who is able to provide a service to a platform, but may be 

15 imwilling to provide this service if it caimot be assured that the platform receiving the 
service is indeed trusted, the TPM 62 provides this CA certificate to the RSP 64 (step 
68). The RSP 64 is liien able to check by using the public data of the CA that the 
certificate has been validly issued by the CA 62. It is assxraied here that the RSP 
trusts both the CA and manufacturers of genuine trusted platforms. If this is the case, 

20 there is now an effective chain of trust — the RSP trusts the CA, therefore trusts that 
the certificated information (which purports to show that the TPM has been certified 
by the trusted platform manufacturer) is valid, and therefore trusts that the TPM 62 is 
indeed a legitimate product of known trusted platform manufacturer 61. Privacy 
concemts for the trusted platform can also be met in respect of the RSP - this 

25 arrangement need not reveal to the RSP which TPM it is interacting with (ie, this can 
be arranged such that all that the RSP will be able to establish is that it is interacting 
with a bona fide TPM manufactured by a known - and trusted - manufacturer). 

As indicated above, a significant difficulty with this scheme is that the CA is now a 
30 weak point in the system — it is able to correlate the identities of the TPM (and 
probably that of a large number of TPMs). If the CA reneges on an agreement not to 
map endorsement keys to identities, or has permission to do such mapping but the 
CA's database is compromised, the identities of all TPMs which have been certified 
by that CA will probably also have been compromised. 
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Two different schemes, and associated architectures, will now be described which 
address this difficulty. The first scheme sets out how a particular construction of the 
certificate given to a trusted platform module can allow the trusted platform to prove 
5 directly to a verifier (such as a remote service provider) that it possesses a certificate 
which has been validly formed by a trusted manufacturer without revealing the secret 
itself, and goes on to discuss a system architecture in which revocation can be 
satisfactorily carried out. The second scheme, which can as broadly described be 
considered a general scheme of which the first scheme is also an example (thou^ a 
10 specific version of the second scheme, using a different specific algorithm to the first 
scheme, is also described), is a group signature scheme adapted to provide evidence 
for use in revocation. 

First Scheme 

15 

In aspects of the invention, the approach taken to solve this problem is to find a 
mechanism that will allow the TPM itself to convince a verifier, who may be an RSP, 
a certificate authority, or a revocation agency, that it has a trusted manufacturer's 
certificate, but in such a way that the verifier will not be able to distinguish a 

20 particular TPM. The TPM is therefore able to provide direct proof that it is a 
legitimate TPM, rather than simply gives its endorsement key to the CA and then an 
RSA will have indirect proof (by reference to a CA). The relationships involved are 
shown in Figure 7 (with reference numerals as for Figure 6 where the same element is 
referred to). The trusted platform manufacturer 61 provides the TPM 62 with a 

25 unique identity and certifies this identity (step 65), though as will be seen below, this 
certification takes a new form. It is therefore possible in such an arrangement for no 
CA 63 to be required to take a role in certifying this manufacturer's certificate 
(though, as will be seen below in respect of revocation, there may still be a role for 
CAs in allowing RSPs to determine whether TPM credentials have been revoked — 

30 this is represented by dashed line 73 here). Instead, when a verifier 64 needs to 
establish that a TPM is a legitimate product of a trusted manufacturer, there is an 
interaction 71 in which the TPM does not reveal its unique identity to the verifier, but 
does indicate (to an appropriate standard) that it is extremely improbable that its 
certificate could have been formed in any way other than the proper manner by the 
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trasted manufacturer. As will be discussed further below, this interaction 71 can be 
an iterative interaction between the verifier 64 and the TPM 62 (such an interactive 
proof with a prover and a verifier, where the prover convinces the verifier of a 
statement without revealing any information about how to go about proving that 
5 statement, is known as a zero-knowledge proof), or can be achieved (with clear 
advantages in commxmication efficiency at the expense of some computational burden 
to the TPM) by provision of a signed mathematical structure to the verifier by the 
TPM for evaluation by the verifier. In either event, the verifier uses public data from 
the trusted platform manufacturer to determine that the certificate must have been 
1 0 formed in the proper mamier by the trusted platform manufacturer. 

A direct proof scheme according to an aspect of the invention will now be described. 
This scheme will be described in two versions: one version is a zero-knowledge proof 
requiring iterative interaction between TPM and verifier, and the other version 

15 involves anonymous signature of a mathematical structure by the TPM, with the 
verifier then able to determine that the certificate of the TPM is validly formed by 
resolution of the mathematical structure. In both cases, certification by the 
manxxfacturer uses the condition c = {tiwr" + t2f^ mod where m is a TPM's identity 
and {e\, €2, ti) are public parameters of a TPM manufacturer. Of these private 

20 components, n is a RSA modulus, e\ and ^2 are RSA exponents, and t\ and are 
randonnily chosen integers. d\ is a private parameter derived from e\. This condition 
can be proved in zero-knowledge by (log e{) + (log e-i) rounds. Since neither e\ nor 
is a security parameter, both can be chosen to lie within a reasonably small range (in 
the current version of TCG specification, e = 2^^ + 1 and n has 2048-bit size). The 

25 security of this scheme is based on the assumption (proposed by J. Camenisch and M. 
Stadler, "Efficient group signature schemes for large groups". Advances in Ciyptology 
- CRYPTO 'P7, LNCS 1294, pp. 410-424, Springer-Verlag, 1997) that if n is an RSA 
modulus with unknown factorization; there exist two integers t\ and t2 in G*„ and two 
small integers e\ and ez in C**<^„) such that it is hard to compute values m and c such 

30 that c^* = {t\m^^ + ti) mod n. In order to forge a valid pair (m, c) with c^* = t\nf^ -h t2 
mod w, an attacker might start by (a) choosing c and then computing m = ((c^* - ti)/ 
t\Y^ mod n\ or (b) choosing m and then computing c = (t\nf^ + t^f^ mod w. In either 
case, the attacker has to solve the RSA problem, so forgery of a valid pair can be 
considered to be hard. 
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Where terms are not specifically identified in this application, this is generally 
because they are in general use in cryptography and will be readily understood by a 
person skilled in this art. Alternatively, the reader is directed to an appropriate 
5 cryptography primer (such as that provided in the text and references of RSA 
Laboratories' Frequently Asked Questions About Today's Cryptography, found at 
http://www.rsasecurity.coni/rsalabs/faq/index.html). 

Each scheme employs as a fundamental building block a technical primitive used to 
10 verify that Qi, x = /z", y ^h'.z^ h""") is a Diffie-Hellman (DH) tuple and that a prover 
knows a secret v. Different technical primitives are used for the zero-knowledge 
proof and the signature version. Both primitives use the same inputs, as follows: 



Public inputs : 

15 n — RSA modulus, if - a hash function with output size close to\n\ 

K — a. smallest number to satisfy P = Kn -f 1 (prime), 
a e Z*(a ^l\h^ modP 
X = h"" mod P,y^ A" mod z = modP 



20 



Private input (of the Prover) : v 

The primitive for the interactive scheme is here termed DH-interaction(A, x, y, z). It 
comprises the following steps: 



1. Verifier chooses at random l<a<n^l<b<n and sends to Prover C = h^x^ 
25 mod P. 

2. Prover sends to Verifier R = H{C mod P). 

3. Verifier accepts if i? ?= H(y^z^ mod P) or rejects otherwise. 

This primitive is obviously simulatable (a property of a zero-knowledge proof is that 
30 it can be simulated accurately without providing information concerning the secret to 
any third party), because anybody without knowing v can compute C = h^x^ mod P 
and R — H(y^z^ mod P). This simulation has identical distribution as that firom a real 
proof. 
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The primitive for the signature scheme is here termed DH-signature(A, x, j;, z). This 
works between Prover and Verifier as follows: 

5 1 . Signer chooses at random 1 <b <n and then computes 

/ = modP, g = jc* modP 

J* = &-v* vvmodn 

10 The signer sends VerijBer (w, s)as2i signature on the DH tuple (pc, y, z). 

2. To verify the signature. Verifier computes 

/ = /?>^modP, 
15 g' = A^z^modP, 

Verifier accepts if the check w' ?= w succeeds, and rejects otherwise. 

20 DH-signature(/i, x, y, z) is a Schnorr based signature (see C. P. Schnorr, "Efficient 
identification and signatures for smart cards". Advances in Cryptology-Crypto '89, 
LNCS 435, pp. 239-252, Springer-Verlag, 1990) signing a DH tuple (x, y, z) under a 
key (v, h, x, y, z, w, P) where v is a private parameter and (A, x, y, z, n, P) are public 
parameters. 

25 

The use of these primitives to provide direct proof schemes suitable for the trust 
relationships set out in Figure 7 will now be discussed. The trustworthy manufacturer 
of trusted platform modules (hereafter TPM manufacturer) needs the following to be 
able to certify TPMs that it produces: one RSA modulus w, two public parameters e\ 
30 and e2, and one private parameter di computed such that = 1 mod <p(n), A value 
K is chosen such that P =Kn + I is prime. It is desirable that n is sUghtly smaller than 
2048 bits, jST is a smallest value to make P prime, and that P is about 2048 bits, ti and 
t2 are randomly chosen in G*„ so that their eith-root or e2th-root are hard to compute. 
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The TPM manufacturer then certifies a TPM it produces as follows: firstly the identity 
m is chosen such that 1 < w < and after this the TPM manufacturer certifies m by 
computing c = {t\rrf^ + t2f^ mod n. m and c are then stored on the TPM. Optionally, it 
is possible to use Chaum's RSA bUnd signature scheme (see D. Chaum, "Blind 
5 signatures for untraceable payments". Advances in Cryptology - Crypto '82, Springer- 
Verlag (1983), 199-203) so that the TPM manufacturer will not know the values of m 
ore. 

The direct proof scheme described here is designed to achieve the following goal: at 
10 the end of the scheme run, 

1 . a verifier is convinced that a claimed TPM knows m and c where c = (tim^^ 
^t^f' modn. 

2. the verifier doesn't know m or c. 

15 To convince the verifier of 1) above, TPM sends the verifier 
X = A'"*^ modP and y = hf^ modP and then convince the verifier of the structure 
of X and y, where (A, ei, ^2) are public input and (m, c) are private input from TPM. 
After that, the verifier accepts 1) if j; = x^'*^^^ jj^q^j p reject 1) otherwise. 

20 A general case protocol for obtaining such a proof of the structure of x and y follows 
below. This protocol appUes to both zero-knowledge and anonymous signature 
versions, with the differences between the application of the protocol in the two 
versions being indicated. The zero-knowledge version derives in part from our earlier 
British Patent Application No. 0104140.9, filed on 20 Feb 2001, whereas the 

25 signature version derives in part from the Schnorr signature scheme (see C. P. 
Schnorr, "Efficient identification and signatures for smart cards". Advances in 
Cryptology-Crypto '89, LNCS 435, pp. 239-252, Springer-Verlag, 1990). In the zero- 
knowledge version, DH-interaction will be used in the protocol and in the signature 
version DH-signature will be used instead. 

30 

The protocol applies generally to any e rather than specifically to e\ and ^2 , so e is 
used instead of e\ or ^2, and Jf" ~h modw is used instead of 
X = /z'"'' modP or y = If'^ modP . The specified protocol is thus suitable for proving 
bothx and;/. 

35 
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Protocol ( /i" = mod 77 ): 

Prover convinces Verifier that the public inputs (e, n, P, X, 8(e)) satisfy 

S(e) = h^' modP and X = h^ mod P and that Prover knows a and jS. 



In this protocol, S(/) ~ h^' modP . The protocol will abort if any check in 
either DH-interaction or DH-signature does not succeed. 



Prover and Verifier run the following protocol by starting firom y = e. 



while y > 1 do 
{ 



1. 



Prover performs the following steps: 



ift is even: y <— S(y) , sends x to Verifier, 
if t is odd: y <r- S{y — 1) ^ sends x and y to Verifier. 
2. if t is even: both run DH-interactionC^, x, x, b(jj) or DH-signature(A, 



when y= I, both mn DH-interaction(A, h, S(l), X) or DH-signature(/2, h, 6(1), X), 
Verifier accepts if all of the above process succeed or rejects otherwise. 

After running the above protocol twice: one with {e\, a\ == c^^ mod n, jSi = c mod n), 
and the other with (^2, 0^2 = m^^mod n, ^2 = mod n). Verifier accepts the structure of 
= -f t2 mod n) if 8{e\) (namely 3;) firom the first run and 6(^2) (namely x) firom 
the second run satisfy 8{e\) = 6(^2) 



3. 




} 
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One fundamental difference between the zero-knowledge and the signature versions is 
that different primitives are used (as discussed above). The other fundamental 
difference is that the interactive version involves in some sense a synchronous 
working through of the protocol (there is a stream of interactions between prover and 
5 verifier in working through the protocol) but the signature version is essentially 
asynchronous (the prover works through the protocol to produce a mathematical 
structure, signs this mathematical structure, and provides it to the verifier, who checks 
the signature and works through the mathematical structure to obtain verification). 

10 For the zero-knowledge scheme, each DH-interaction needs 3 modulo exponentiations 
- the TPM computes one and the verifier computes two. The whole interactive proof 
will cost about 5.5*((log ei) + (log €2)) modulo exponentiations - the TPM computes 
about 2.5*((log ey) + (log €2}) and the verifier computes about 3*((log ei) + (log ^2)). 
The communication rounds are (log ex) + (log ez). If choosing \ei\ = {ez] = 16, TPM 

15 will need to compute 72 modulo exponentiations, and to commimicate with the 
verifier in 32 rounds. 

For the signature scheme, each DH-signature needs 6 modulo exponentiations - the 
TPM computes two and the verifier computes four. Signing a signature will cost about 
20 4*((log ei) + (log €2)) modulo exponentiations, and verifying a signature will cost 
about 6*((log ei) + (log ^2)). The communication cost is now only that of a single 
message with about 2.5*((log ei) + (log e2))*(log P) bits. 

A specific case of the signature scheme will now be described ~ this case is chosen to 
25 be particularly suitable for modification of existing trusted platform technology. Here 
we shall choose e\ = 2^^ + 1 and €2 = 2. 

TPM first creates x and y by randomly choosing a gr (1, « - 1], and computing h = 
mod P, X = A'"' modP and 3; = x'^ * p y?M makes A, x, and y available 

30 so that these can be obtained by an the verifier. 

TPM makes two signatures respectively on x and 3; as follows. 
1 . Signature (x = /z'"^ modw ): 
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TPM chooses at random 1 <b<n and then computes 

^ f = h^ modP, g = z^ modP 

s^b — m*umodn 

2 

10 TPM chips (z, u, s) as a signature on the structure of x^h"" modn . 

To verify this signature, the verifier computes 

/'=/z'*z"modP 
g'=zz' modP 
u^^H{z,x,f\g^) 

the verifier accepts (x = modP) if the check u' ?= u succeeds, and rejects 
this otherwise. 



20 2. Signature {y-h"" mod?2 ): 

The TPM computes 7} = c^' modw, (0 < z < 16) - these values can be used as long-term 

secrets of the TPM. The TPM needs to store such secrets securely, for example, only 
storing an encrypted version of them outside of the TPM. 

25 

To do signing, the TPM randomly chooses (1,^-1] (0 < z < 15) and computes 

/z,. =/7'*^modP(0<z<16) 
y;=/z^'modP(0<z<15) 
30 gi = h^' modP (0 < i < 15) 

g,,^h^lmodP 

Si = bi - jr. * vmodn (0 < z < 15) 

The TPM chips the following data as the signature on the structure of 
35 y = h^ modw: 
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h, (0<i< 16), v,5, (0 < z < 15) 



To verify this signature, the verifier computes 

f! = h'' * hr modP (0 < z < 15) 
g] = /z/' * /z/^i modP (0 < z < 15) 

and then checks v' ? = v. 



15 On the basis of these signature verifications, the verifier is convinced of the following. 

(1) From DH-signature, the verifier is convinced of 

ce(l,^z-l],Ao ^h^'raodP.h^ ^hf^ modP 
by checking/ 0 and g o in v. 

go = /Zo°*/<modP 

(2) From DH-signature and (1), the verifier is convinced of 

c'' e (1,/z - l],/z, = /z^'^ modP,/z,^i = A''' modP 
25 by checking /'/ and g 'i in v. 

/'.= /z^'^/z;modP 
g-;. = /z;'*/z,;jmodP 

(3) From DH-signature and (1), the verifier is convinced of 

30 

ce (l,/z-l],/io =/z''modP,j; = /?jgmodP 

by checking/ 0 and ^-'16 in v. 

A = ^'°*^oniodP 
g^\6 = '^'6*y'niodP 
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From (1), (2) and (3), the verifier is convinced of 

:); = A<"^^>' *^'*^modP 
= /z^'''*^modP 
= /z" modP 

After having two succeeded verifications on Signature(x^ h'''^ modP) and 

Signature(y- h"" modn) respectively, the verifier as Verifier can therefore accept 

the construct of ( c^''"^^ = t^nt^ + mod n ) if 3; = jc^»*A j^od P. The TPM has therefore 
directly proved to the verifier that it has a secret m with a certification c where c = 
(^i7w^2 + f^^i j3^Q(j a^j^^^ jj^g ^Qjjg gQ without reveaUng the values of either m or c. 

A particularly appropriate way to implement a hash fimction with output size close 
to 2048-bit is to use the well-known hashing algorithm SHA-1 (because SHA-1 is 
currently already used in a conventional TPM) 12 times with concatenated results, 
i.e., H{x) = SHA - l(jc + 1) || SHA - l(x + 2) || ... j] SHA - l(x + 12) , where || is 
concatenation. 

In this special case of the direct proof scheme according to an aspect of the invention: 
ei = 2^^ + 1, ^2 = 2, and |P| = 2048. In order to sign the construct of c = (tim^^ + ^2)''^ 
mod n, a TPM needs to 

1 . generate 1 8 random numbers with 2048-bit size, 

2. compute 55 RSA modulo exponentiations in which 54 have 2048-bit length 
modulus and exponent; and one has 2048-bit modulus and (log iQ-bit 
exponent, 

3. compute 17 multipUcation modulo, 17 subtraction modulo and 1 division 
modulo with 2048-bit modulus, 

4. compute 2 hash-fianctions, equivalent to 24 SHA-1 fimctions, and 

5. send a signature with the size of 21*(log P) + 19*(log n) bits, approximately 
80k-bit in size. 
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An exemplary conventional TPM includes a crypto accelerator capable of computing 
a 2048-bit RS A signature in 500 ms. To signing the structure of c = (tim^^ + t2Y' mod 
n once, the TPM will need to compute 55 RSA modiilo exponentiations, which would 
take about half minute - however, this can be precomputed, and so will not provide an 
5 unacceptable overhead for TPM-verifier interaction. 

While using such direct proof schemes to prove a TPM's identity to an RSP has the 
clear advantage of removing the Certificate Authority firom being a point of weakness 
in the overall system, there is a potential accompanying disadvantage. This 

10 disadvantage is that it is not straightforward to revoke the certification on a TPM's 
secret (which in the prior art could straightforwardly be done by the CA - which 
would merely have to revoke the certificate that it had granted). A TPM can convince 
an RSP that it has a trusted manufacturers certificate, but does not allow the RSP to 
distinguish a specific TPM. Each RSP can construct its own blacklist of rogue TPMs 

15 (as the direct proof scheme allows the RSP to distinguish one TPM it has interacted 
with firom other TPMs it has interacted with, as is discussed fijrther below), but it 
cannot transfer such information as it knows about the TPM usefiiUy to another RSP 
(or any other party) - there is no way to match up the RSP's own blacklist with any 
other blackUst, because the RSP does not learn the identity of the TPM and has no 

20 associated transferable data. If an attacker obtains one identity, for example, by 
physically breaking one TPM, he can convince those RSPs who haven't had a record 
of this identity in their own black list of the validation of the identity. 

Use of a direct proof scheme, by definition, makes it impossible to create a globally 
25 distributed revocation list unless a rogue platform's secret primitives have been 
revealed to the legitimate community. Where trusted platforms are used, it is unlikely 
that this will occur - so it can be assumed that any given platform caimot learn 
directly firom the bad experiences of other platforms. In a fiature world of advanced 
peer-to-peer architectures, therefore, even if a platform knew that there was an 
30 outbreak of a rogue TPMs, the platform couldn't be given a new "rogue definition" 
(similar to a new vims definition) to detect those rogues unless the extracted 
primitives had become known to the legitimate community. Thus an entire network 
might shutdown because of fears of broken trust. If the primitives have been created 
through a blind scheme (so that even the manufacturer doesn't even know them and 
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cannot therefore impersonate any TPM), then this problem becomes even more 
serious. 

This problem is fundamental to direct proof schemes because the purpose of a direct 
5 proof scheme is to prevent correlation of identities. If a direct proof scheme is 
effective, it's impossible for one party to give information to a second party that 
permits the second party to recognise that his correspondent is also the first party's 
correspondent. So if a TPM is broken, its secret primitives extracted and replicated 
into software simulations of TPMs, it's impossible to put that TPM onto a distribution 
10 list unless the extracted primitives become known to the legitimate commimity, as 
well as to the rogue commxmity. 

Accordingly, in a further aspect of the invention there is proposed an improved 
system architecture which allows for effective revocation even where the TPM is 

15 adapted to provide direct proof that it has a vahdly formed credential to an RSP 
without the TPM revealing its credential to the RSP and without requiring a revoking 
Certificate Agency to possess the endorsement identity of the TPM. This system is 
described with reference to the form of direct proof discussed above, but it should be 
appreciated that this architecture is generally applicable to any arrangement in which 

20 a TPM is adapted to provide direct proof that it has a vahdly formed credential to a 
verifier without the TPM revealing its credential to the verifier, and that where the 
specific direct proof used above is referred to below, such reference can be replaced 
with a reference to any other direct proof without going beyond the invention in this 
aspect. 

25 

The system involves four sets of entities, as shown in Figure 7: TPM manufacturers 
61, TPMs 62, Certificate Authorities (CAs) 63, who also play the role of revocation 
agency, and RSPs 64. 

30 As described above, in order to implement the exemplary direct proof scheme, each 
TPM manufacturer has parameters: w, K, P, 62, e-i, du ti and tz, where w, K, P, ^2, 62, tx 
and t2 are public parameters and d\ is a private parameter. Each TPM has secret 
parameters m and c satisfying c = {tim^^^ + t2Y' mod n. Different parameters may be 
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used by the TPM manufacturer and the TPM if a different direct proof scheme is 
employed. 

In this arrangement, each CA has a traditional asymmetric key pair, Pca and Sca- Each 
5 CA also has a number of public identities, IDca, which could be the CAs public 
name, hca, concatenating with an identity of a specific purpose, Pa, i.e., IDca = "c^H 
Pa. Each RSP has an authenticated version of Pca- 

In the scenario of interest, a trusted platform device (TPM) needs to communicate 
10 with a remote service provider (RSP) to access a purpose (here, a group of specified 
services) Pa, and a certificate authority (CA) is trusted by the RSP to issue a 
certificate for Pa and to maintain a black list of those TPMs which should not be 
allowed to access Pa- This is accomplished as follows. 

15 The TPM first creates a traditional asymmetric key pair, Ptpm and iStpm (e.g., an RSA 
key pair), and then signs the structure of c = (t\m^'' + ^2)^* mod n under the secret 
values of m and c. As described above, to do this the TPM randomly chooses h, 

computes x and y, where x = h!^^ modP and y = h"^ modP , and makes two 

signatures: Signature{x = A'"' modn) and Signature{y = A""^ modn). TPM sends the 
20 signatures including x and y with Ptpm to CA. After the verification of the signature 
succeeds, CA is convinced that the TPM has a pair (m, c) satisfying c = {tim^^^ + tif' 

mod n, and the given h and x satisfy x^lf''^ mod P. Note that this is simply a 
fiirther use of the direct proof scheme described above for proof by TPM and 
verification by RSP - the only significant difference here is that the verification is by 
25 the CA. It also follows that any other effective direct proof scheme could be 
employed to carry out this step. 

The CA then sends to the TPM IDca (optionally, the TPM can simply access IDca 
fi-om a trusted public domain). The TPM computes hcA and x' such that hcA = H(JDca) 

30 and x'=hcA modP. TPM computes DH-signature(/2, Jica, ^0 as described above 

and sends the signature to the CA. The CA first verifies DH-signature(/2, hcA, x, x'). If 
the verification doesn't succeed, CA refixses the TPM's certificate request. Otherwise 
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CA checks if is in a black list. If x' is in the black list, the CA also rejects this TPM. 
Otherwise CA certifies Ptpm by using Pca and Sca in a usual way (as the same as the 
private CA in the current version of TCG specification) and records x' and the 
certificate of Ptpu- An appropriate way to manage this is for the CA to records' with 
5 Ptpm for internal access only and to list Ptpm i^a a publicly accessible revocation list. 



Again, it should be noted that an alternative direct proof scheme to that using DH- 
signature could be employed here without straying outside the scope of this aspect of 
10 the invention. All that is necessary is for the direct proof process to produce a value 
such as x' that is representative of a TPM secret without revealing that secret, in such 
a way that the CA can establish for itself a list of TPMs with certificates issued to 
those TPMs. 

15 In the same way as in the current version of TCG specification, to access a service in 
the group of Pa provided by RSP, the TPM authenticates itself to RSP with the 
certificate of Ptpm- RSP verifies the certificate and also checks whether this certificate 
is in CA's revocation Ust. For example this can be achieved by using a traditional 
Certificate Revocation List (CRL). 

20 

The CA will generally learn of rogue TPMs by receiving certificates Ptpm which it 
has issued from RSPs (or other parties that have interacted with the rogue TPM) 
where these certificates have been used, for example to access a particular service, in 
such a way that it is apparent that the TPM identity is not, or should not be, valid. 

25 The CA is then able to match the certificate Ptpm with the associated provided in 
the verification of the relevant TPM. The certificate Ptpm can then be placed on the 
CRL. The rogue PTM will not be able to obtain a fiuther certificate as the same value 
ofx' will be generated during the verification process - as indicated above, the CA 
will detect this during verification and will refiise to provide a certificate to the rogue 

30 PTM. 
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Second Scheme 

As indicated above, the second scheme is a group signature scheme with revocation 
evidence. As will be described below, a specific scheme described is a further 
5 developed version of that described by G. Ateniese, J. Camenisch, M. Joye, and G. 
Tsudik in "A practical and provably secure coalition-resistant group signature 
scheme" in Advances in Cryptology - CRYPT 2000, LNCS 1880, pp. 255-270, 
Springer-Verlag, 2000. In the scheme set out below each TPM has a unique 
endorsement key z and the corresponding key certificate (u, e) satisfying = a^b mod 
10 where (a, b, n) are public parameters of a TPM manufacturer - /2 is a RSA modulus, 
and a and b are randomly chosen integers. The security of this scheme is based on the 
strong RSA assumption and decisional Diffie-Hellman assumption. This group 
signature scheme is particularly efficient, and benefits from an existing security proof 
in a random oracle model in Ateniese et al (referenced above). 

15 

A general group signature scheme with revocation evidence generating properties will 
now be discussed. This general scheme comprises six procedures: 

SETUP: On input of a security parameter 1, this probabilistic algorithm outputs 
20 the group public key PK (including all system parameters) and the group 

secret key SK for the group membership certificate issuer (CI). 

JOESf: A protocol between CI and a user that results in the user becoming a 
new group member. The user's output is a membership secret and membership 
25 certificate. 

REVOCATION EVIDENCE CREATE: A probabiUstic algorithm that on 
input of a group public key, a membership secret, a membership certificate, 
and a revocation parameter, outputs revocation evidence. 

30 

SIGN: A probabilistic algorithm that on input of a group pubUc key, a 
membership certificate, a membership secret, revocation evidence, and a 
message m, outputs a group signature of m with revocation evidence. 
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VERIFY: An algorithm for establishing the validity of an alleged group 
signature of a message with revocation evidence with respect to a group public 
key and a revocation parameter. 

5 REVOCATION: An algorithna for listing revocation evidence from a group 

signature into a revocation list. 

The following properties should, in a preferred scheme of this type, all be satisfied: 

10 Correctness. Signatures produced by a group member using SIGN must be accepted 
by VERIFY. 

Unforgeability. Only group members are able to sign messages on behalf of the group. 
Anonymity. Given a valid signature of some message, identifying the actual group 
member is computationally hard for everyone including the group membership 
15 certificate issuer. 

Linkability. Deciding whether two different valid signatures with different revocation 
evidence were computed by the same group member is computationally hard. 
However, deciding whether two different valid signatures were computed v^th the 
same revocation evidence is easy; 
20 Traceability/Revocability. If a group member secret and its membership certificate are 
published, everyone is able to open a valid signature signed under this secret and 
certificate. Without the group member secret and membership certificate, none 
can trace a valid signature to the actual gi'oup member. However, anyone can trace 
any group signature to revocation evidence, therefore a group membership to a 
25 specified application purpose addressed by revocation evidence can be revoked. 

Coalition-resistance. A colluding subset of group members (even if comprised of the 
entire group) cannot generate a valid signature that is signed imder an extra group 
member secret and the corresponding valid membership certificate. 

30 It is obvious that if any attacker gets one pair of the member secrets and membership 
certificates, he can make many "valid" copies. A group member's general signing 
ability cannot be revoked unless the group member secret and its membership 
certificate are published. However, although, group signatures with revocation 
evidence are group signatures without traceability of the membership certificate there 
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is traceability of the membership with respect to revocation evidence. The revocation 
evidence for a particular use of a group signature (a signature by a group member for 
a particular purpose) is unique for a particular group member secret and membership 
certificate and purpose. Hence the link between revocation evidence and group 
5 signatures for a particular purpose is universally verifiable. We can therefore 
construct a revocation approach above and beyond that of the ordinary method of 
secret or certificate revocation. 

The group signature scheme of Ateniese et al ("the ACJT signature scheme") will 
10 now be set out, before the modifications to achieve the present scheme are described. 

A group manager {GM) has a public key PK = {n, a, b, h, IF, A\ where n is a 
product of two safe primes, and q, a, g, h andy are quadratic residues modulo n, I 
is a security parameter, and F and A are two intervals. GM has the corresponding 
15 private key SK = (p, x\ where p and q are used to issue group membership 
certificates, and x = loggy is used for membership revocation. 

A group member P/ has a membership secret z/ and a membership certificate (w/, e/) 
satisfying m/' =a^'fcmod/2 . The value Zf is selected jointly by Pi and GM from an 
20 appropriate integer range, A, It is selected in a secure maimer that ensures: (1) GM 
obtains no information about this value and (2) both Pi and GM can verify that each 
other must make their contribution correctly. The values Ci is a prime number selected 
by GAf from another appropriate range, F GM keeps a record of (m,, e/) to identify P,-. 

25 When Pi signs a message on behalf of the group. Pi proves membership in the group. 
To do this, he effectively proves the knowledge of (z/, Ui, e,). For instance, to sign a 
message m on behalf of the group, Pi first chooses w gr {0, and computes 
2] = u^y'^'mo&n , = g""" modn , and = g^'h'' mo&n . P/ then creates a signature of 
the knowledge of integers a, ;}f, and 5 such that b ^T^^a'^y'^ modn, 

30 l = r/^-^modn, r2=g^^mod;2, and T^^g^'h^ modn hold, where a^T and 
G z/ , on the message m. By using the notation introduced by Camenisch and Stadler 
in [CS97], this signature can be denoted as 
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A a e 7" A >ff € /d](m). 
By verifying this signature, the verijBer is convinced that 

5 

a^b = T.^'y-^ = r^'j;-"^ = (T,y~'y modn , 
and further 

10 up' = a'^'bmodn with = j3modn,u- = T^y'^ modn,e- = amodw . 

This group signature can be regarded as a signature of knowledge of (1) a value Zf ezl 
such that a^'b is the value which has an ^rth root, and of (2) the erth root of a^'b such 
that it is ElGamal-encrypted in (Tu T2) under y, where ei is the first part of the 
15 representation of T3 w.r.t. g and h and that e/ Ues in T, 

As with all group signature schemes, GM and only GM can assert the signature to P/ 
because GM has the ElGamal-decryption key, and GM can therefore compute the 
value m' TiliTif = ut that identifies P/. 

20 

Modifications to this scheme to provide a group signature scheme with revocation 
evidence will now be described. The parties involved, and the processes, are 
illustrated schematically in Figure 8 (for a version emplojdng a revocation agency) 
and Figure 9 (for a version not emplo3dng a revocation agency). This new scheme 
25 makes the following three changes to the ACJT group signature scheme: 

1. We do not allow any entity except for the TPM 82 itself to retrieve the 
endorsement key certificate firom a signature, otherwise this entity can break 
the anonymity. Therefore we omit GMs membership opening ability and keep 
only certificate issuing ability, and we call this entity an endorsement key 
30 certificate issuer (CI) - it is preferred that CI 81 will be a manufacturer of 

genuine TPMs. 
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2. For enable revocation of a group signature for a particular purpose, we require 
a group member 82 to create self-certified revocation evidence for that 
particular purpose, using for example, a revocation agency 83 that specialises 
in revocation for that particular purpose. This revocation agency 83 can 

5 correlate different signatures that are signed under the same TPM endorsement 

key and key certificate for the same application purpose. Alternatively, 
verifiers may maintain their own revocation lists if detectors of rogue TPMs 
make such information publicly (or otherwise appropriately) available. 

3. We simplify the process of creating a TPM endorsement key and issuing its 
10 certificate. The ACJT group signatures are designed for those applications 

where GM and Pi might not trust each other to execute the scheme properly. In 
this TCG application, this process happens during the manufacture of genuine 
TPMs, and it is natural for C/, the TPM manufacturer, to trust the TPMs made 
by them. 

15 

The verifier 84 may be any party that needs to estabUsh the bona fides of a TPM — 
typically, this will be a remote service provider (RSP). 

We now describe the scheme with the six procedures described generally above 
20 exempUfied. 

L SETUP (step 801) 

To initiate a system, the definers of the overall architecture perform as follows: 

25 

1. Choose e > 1, ^, and / as security parameters such that the parameter e can 
properly control the tightness of the statistical zero-knowledgeness and the 
parameter / meets the needs of security requirement of the size of the modulus 
to use. 

30 2. Choose /Li, /L2, Yu aiid yz as lengths satisfying X\> e (/I2 + /c) + 2, /I2 > 4/, and 

n>e (ri ^k) + 2,Y2>M^ 2. Define the integral ranges A = ]2^^ - 2^, 2^^ + 
2^[ and r= ]2^^ - 2^, 2^'^ + 2% 
3. Choose a collision-resistant hash function iif: {0, 1}* -> {0, 1}^. 
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To set up a TPM manufacturer (called CI), CI creates its public key (w, a, g, y, h) 
and the corresponding private key (p\g') by performing as follows: 

5 1. Select raudom secret /-bit primes p\g' such that p = 2/? ' + 1 and q^2q'+ 1 

are prime. Set the modulus n ^pq> 
2. Select random elements a\ b\ c' €r Z* , compute g' = H(c'||lX y' = H(c]\2), 
and h' = Hic]\3\ check if gcd(a' ± 1, n) = 1, gcd(6' ± 1, n) = 1, gcd(g' ± 1, n) - 
1, gcd(y' ± 1, w) = 1 and gcd(A' ± 1, ^7) = 1 hold, if check succeeds, compute a 
10 = a'^ mod b~ b'^ mod g = g*'^ mod 3^ =3^'^ mod and /r = A'^ mod 

otherwise report to CI "Sorry, I have factorised your modulus". This will 
guarantee a, b, g,y,h e QR(n) of order p 'q \ and will also ensure that no one 
knows the discrete logarithm of Qi or g) w.r.t. base gov h (gory^ or h ory), 
all modulo n. 

15 

CPs public key is made available via the usual means (i.e., embedded in some form of 
a public key certificate signed by a trusted authority), hi practice, to prevent framing 
attacks, before certifying this public key, the trusted authority must verify components 
of (n, a, b, g^ y, h). In particular, (1) CI needs to provide a proof to the trusted 
20 authority that n is the product of two safe primes, and (2) CI sends a'^b\ and c' to the 
trusted authority who then checks that gcd(a' ± 1, n) = 1, gcd(ft' ± 1, n) = 1, 
gcd(iy(c1|l) ± 1, w) = 1, gcd(iy(c1i2) ± 1, 77) = 1 and gcd(H{c'\\3) ± 1, = 1 hold, and 
computes a = a'^ mod n^b — b'^ mod n, g = H{c*\[\f mod y = i?(c '||2) ^ mod w, and 
h=H(c'\\ifmodfu 

25 

2. JO/iV(step802) 

To let a TPM (called TPM) become a member of the TPM group,there are a number 
of possible approaches that can be followed. In one exemplary form, TPM and CI 
30 may perform as follows: 

1 . TPM generates a secret exponent z Gr ^4 as its endorsement key, computes v = 
mod «, and sends v to CL 
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2. CI issues the endorsement key certificate {u, e) by selecting a random prime e 
gr rand computing u = (ybf^^ mod n. CI stores (w, e) on TPM. 

It should be noted that there are many possible alternative forms of the joining 
5 process, particularly in the division of tasks between CI and TPM. The following 
three versions are exemplary: 

Version 1. 

10 1. C/ randomly chooses an exponent z gr ]1, 2^^] as TPMs endorsement private 

key, and computes v = a^, 

2. CI generates the endorsement key certificate (u, e) by selecting a random 

prime ^ I^^'' ^» ^ ' ^ ^ ^ and computing u = (ybf^^. 

3. C/ stores (z, w, e) on TPM 

15 4, CI erases all of its knowledge of (z, e). 

Version 2. 

1 . TPM generates a secret exponent z gr ] 1 , 2^^] as its endorsement private key, 
20 computes v = and sends v to CL 

2. CI issues the endorsement key certificate (m, e) by selecting a random prime e 

^R l^^^' -^^^ "^^^'^ and computing u = {vbf^^. 

3. CI stores (w, e) on TPM 

4. C/ erases all of its knowledge of (w, e), 

25 

Version 3. 

1 . TPM generates a secret exponent z gr ] 1 , 2^^] as its endorsement private key. 

2. TPM computes v = a^. 

30 3 . rPM selects a random prime e gr I^^^' ^' + 2^^ ] 

4. TPM imports temporary secret (p\g% and computes d=l/e mod 4j7 'q \ 

5 . TPM computes u = (vfe/. 
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rPM erases all of its knowledge of (p',q'). 

Note that in this join process, we assume: 

5 ■ Connmunication between TPM and CI is secure, i.e., private and 

authentic; 

■ CI trusts that TPM selects the secret z correctly. Otherwise CI and TPM 

have to run the JOIN protocol described in Ateniese et al (see above), where z 
is selected jointly by TPM and CL 
10 ■ TPM also trusts that CI computes the certificate correctly. Otherwise 

rPM will verify if = a^b mod n after received {u, e). 

3. REVOCATION EVIDENCE CREATE (step 803) 

15 This will be described in respect of a model which employs a revocation agency. 
However, it may be noted that using this approach, any correspondent may act as a 
revocation agency and it is therefore possible for each verifier to maintain their own 
revocation lists. For this to be done effectively, when verifiers (or other parties 
interested in the desirability of effective operation of the system as a whole) become 

20 aware of details that should be added to their revocation list, they make these 
available to other potential verifiers. Assume that each revocation agency has a 
unique name, RevocationAgencyName, which can be generated with an application's 
purpose identity, attribute, revocation agency's information, and some randomness (it 
can be noted that this type of name can be generated without a revocation agency 

25 information, but merely information identifying what kind of revocation information 
it is — therefore allowing it to be employed in a model without explicit revocation 
agencies). The revocation evidence w.r.t. this name is created by performing as 
follows - two alternative versions are given below: 

30 Version 1 

1. Input CPs public modulus w, TPMs endorsement private key, z, and 
RevocationAgencyName . 
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2. Compute / = i7(RevocatioiiAgencyName), and check if godif ± 1, w) = 1 
holds, if check succeeds, compute / =/^, otherwise report to CI "Sorry, I have 
factorised your modulus". 

2'. Alternatively, if TPM happens to generate / given RevocationAgencyName, 
5 TPM simply computes / = iy(RevocationAgencyName)^. The probability that 

gcd(f± 1, w) 56 1 is negligible. 

3 . Compute revocation evidence E = 

4. Output 

10 Version 2 

1. Input CPs public parameter a and modulus and RevocationAgencyName. 
Also input TPMs endorsement private key, 

2. Compute / = i?(RevocationAgencyName), and check if gcAif ± 1, w) = 1 
15 holds, if check succeeds, compute / mod n, otherwise report to C/ "Sorry, 

I have factorised your modulus". 
2\ Alternatively, if TPM happens to generate / given RevocationAgencyName, 

TPM simply computes / = //(RevocationAgencyName)^ mod /z. The 

probability that gcd(/^± 1, ;/) 1 is negligible. 
20 3. Compute revocation evidence C = {off mod n, 

4. Output (/;C). 

Note that based on the discrete logarithm assumption, it is assumed that no one knows 
the discrete logarithm of f to the base gov y ox A, and the discrete logarithm of g- or 
25 or h to the basej^ all modulo n. 

4. SIGN (step 804) 

To prove knowledge of the endorsement key z and the endorsement key certificate (w, 
30 e), TPM generates a group signature with revocation evidence on a generic message m 
G {0, 1}* by performing as follows: 

1. Randomly choose w Gr {0, 1}^'. 
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2. Compute T\ ^ uy^ mod n, T2 = g"^ mod n, and T3 = g^h"^ mod n. 

3. Randomly chooser! eR±{0, 1} '^^^^'\r2 e^±{0, l}'^^^'-'\r3 e^±{0, l}^^^^"^ 
2^^^'^^\andr4eR±{0,l}^^''-^'\ 

4. Compute = Ti'^/ia^'y^) mod = Tz^'V/^ mod n, ^fs = e'"^ mod = 
5 g^'^h'^ mod w, and ds = (^jO'^^ mod 

5. Compute c - Ar(^||Ally|MI|61|ri|lr2||r3|lC|!rfill Jall^sIN ds\\m). 

6. Compute = n - - 2^^), 52 = - c(z - 2^^), 5-3 = rs - cew, and ^4 = ^4 - 
(all in Z). 

7. Output (c, ^1, ^2, S3, S4, Tu T2, 73, Q. 

10 

This is a Schnorr-like signature as used in tlie first scheme, and again as for the first 
scheme the signature can be largely pre-computed to minimise the work that is 
required when on-line. In this scheme, signature generation requires 7 (or 1 1) modulo 
exponentiations, and we note that only one of them cannot be pre-computed. 
1 5 Therefore just computation of c, su si, 53, 54, and are done on-line (after discovery 
of m and E). 

For a conventional challenge/response protocol with minimal on-line computation, we 
let 7PM prepare items 1) - 4) above, except for computing d^ in 4), before going on- 
20 line. Later, when communicating with a challenger (namely a verifier), the challenger 
sends information about a revocation agency, RevocationAgencyName, and a fresh 
message, m, as a challenge. TPM creates revocation evidence E = 
if(RevocationAgencyName)^^ mod n (if existing revocation evidence cannot be 
reused), and then finishes the signature by performing items 5) - 7) with ^4 in 4). 

25 

Alternatively, in order to make minimal TPM storage, instead of c = 
H{g\\h\\a\\b\\Ti^^^^^ TPM can compute c as follows: 

Cx=H{g\\h\\a\\b\ 
30 C2-H(cii|ri), 

C4 = H(C3lir3), 

cs-^H(c4dx\ 
c^^H{cs\\di), 
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C7=iy(C6||J3), 
C8-iy(c7||^, 
C9 = H{cz\\dA), 

c-H(c^\\Tn). 

5 

Therefore, signing process can be implemented as follows: 

1 . ZPM imports a, b, g, h (320-bit), n (2048-bit). 

2. r/W imports ci (160-bit). 

10 

OFF-LINE computations 

1 . TPM obtains a TPM-specific secret wi ( 1 60-bit) from the RNG. 

2. TPM obtains a TPM-specific secret wi (1 60-bit) from the RNG 
15 3 . TPM obtains a TPM-specific secret n (3 80-bit) from the RNG. 

4. TPM obtains a TPM-specific secret ^2 (3 80-bit) from the RNG. 

5. TPM obtains a TPM-specific secret (380-bit) from the RNG. 

6. TPM obtains a TPM-specific secret r4 (380-bit) from the RNG. 

7. TPM stores wi, wa, ri, ra, r^, r/^ as part of a new set ^. 

20 

8. TPM computes a non-secret value T\ (2048-bit) = u*Qi"% 

9. TPM computes C2 = H icx\\Ti). 

10. TPM exports Ti. 

25 11. rPM computes a non-secret value Ta (2048-bit) = 

12. rPM computes C3=H(c2\\T2). 

13. TPM exports Ta. 

14. TPM computes anon-secret value T3 (2048-bit) = QO*(g^^). 

30 (A^ could be computed only once and permanently stored in secret). 

15. TPM computes C4 = H (c^WTs). 

16. TPM exports T3. 

17. TPM computes anon-secret value di (2048-bit) = (T'i''')*(a''0*(T2''0*(^3'''')- 
35 18. TPM computes C5 = H (c^di). 
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19. rPM computes a non-secret value d2 (2048-bit) - (/z''0*(g'*O- 

20. 2PM computes 0^"= H {csWdo). 

21. ZRM computes a non-secret value (2048-bit) = g''^ 
5 22. TPM computes cq^H {ce\\di). 

23. TPM stores ci as part of set A. 

ON-LINE computations 

10 

1 . TPM imports RevocationAgencyName (arbitrary length) 

2. TPM computes/(320-bit) = (iy(RevocationAgencyName))^. 

3 . TPM saves / as part of set A, 

15 4. TPM computes non-secret E (2048-bit) = f. 

5. TPM computes C8=iy(c7||£r)- 

6. TPM exports E and erases E. 

7. ZPM generates (2048-bit) =f\ 
20 8. TPM computes C9 = i/(C8|1^^4). 

9. rPM erases ^/4. 

10. 7PM imports challenge m (arbitrary length). 

1 1 . TPM computes a non-secret value cio = H{ci^\\m). 
25 12. IPMsetc = cio. 

1 3 . TPM saves c as part of set A. 

14. TPM exports c. 

15. TPM computes non-secret value si (380bits) = ri - c*(e - 2^^^). 
30 16. TPM exports ^1. 

17. TPM computes non-secret value S2 (380bits) = + c*z. 

18. TPM exports ^2. 
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19. 7PM computes non-secret value S3 (380bits) = rs - c'^W2. 

20. rPM exports 53. 

21. 7PM computes non-secret value S4 (380bits) = ^4 + 
5 22. 3PM exports ^4. 

TPM erases set A. 

5. VERIFY (step 805) 

10 

A verifier checks the validity of a signature (c, ^1, S2, S3, S4, T\, 72, T3, Q - using the 
example of the second version of revocation evidence, though the first version could 
equally well be used - of the message m by performing as follows: 



15 1. Check if C is in a revocation list maintained by a trusted revocation agency, 

who has a name — RevocationAgencyName, if yes reject the signature, 
otherwise carry on. (As indicated above, the verifier may maintain such lists 
itself). 

2. Compute 

c- = H(g\\h\\y\\a\\bm\T,\\T,\\C\\ 
20 b%'' l{a'' ) mod n || T/" / g'^ modn || 

V" modn || T^'g'^-'^'' h'' modn || (a/^ C modn || m). 

3. Accept the signature if and only if c = c', and 5i e ±{0, 1} + S2 e ±{0, 
1}^<^^*>^\^3 e ±{0, l}<^'*''-''^'^*\mds, e ±{0, 



6. REVOCATION (step 806) 

25 

If, for whatever reason, a TPM should be revoked for a particular purpose identified 
by RevocationAgencyName, C is placed in a revocation list. In different 
embodiments, this may be a list maintained by a Revocation Agency, or may be made 
available to potential verifiers for them to maintain their own lists. 

30 
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The security of the scheme will now be considered. The security of the ACJT group 
signature scheme is based on the strong RSA assumption and decisional Diffie- 
Hellman assumption. 

5 The strong RSA assumption (see for example: N. Baric and B. Pfitzmann "Collision- 
free acciraiulators and fail-stop signature schemes without trees", in Advances in 
Cryptology - EUROCRYPT '97, LNCS 1233, pp. 480-494, Springer-Verlag, 1997; E. 
Fujisaki and T. Okamoto, "Statistical zero knowledge protocols to prove modular 
polynomial relations" in Advances in Cryptology - CRYPTO ' P7, LNCS 1297, pp. 
10 16-30, springer- Verlag, 1997) strengthens the widely accepted RSA assumption that 
finding e^^-roots modulo n ~ where e is the public, and thus fixed, exponent - is hard 
to the assumption that finding an e^^-root modulo n for any e>lis hard. 

Definition of Strong RSA Problem - Let n = pq be an RSA4ike modulus and let G be 
15 a cyclic subgroup ofL^of order #G, flog2(#G) 7= h- Given n and z e G, the String 
RSA Problem consists of finding u eG and e e Z^^ satisfying z=if mod n. 

Definition of Strong RSA Assimiption - There exists a probabilistic polynomial-time 
algorithm K which on input a security parameter Iq outputs a pair (n, z) such that, for 
20 all probabilistic polynojniaUtime algorithms P, the probability that P can solve the 
Strong RSA Problem is negligible. 

The Diffie-Hellman Assumption (W. Diffie and M. E. Hellman **New directions in 
cryptography", IEEE Transactions on Information Theory, IT-22(6): 644-654, 1976.) 
25 appears in two "flavours": (i) the Computational Diffie-Hellmman Assumption 
(CDH), and (ii) the Decisional Diffie-Hellman Assimiption (DDH), (see D. Boneh, 
"The decision Diffie-Hellman problem", in Algorithmic Number Theoiy (ANTS-III), 
LNCS 1423, pp. 48-63, 3pringer-Verlag, 1998) 

30 Definition of Decisional Diffie-Helhnan Problem - Let G = (g) be a cyclic group 
generated by g of order #G, flog2(#G) 1 = /g. Given g, ^, and / e G, the 
Decisional Diffie-Hellman Problem consists of deciding whether the elements g^ and 
g^ are equal 
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This problem gives rise to the Decisional Diffie-Hellman Assumption, which was first 
explicitly mentioned by Brands (S. Brands "An efficient off-line electronic cash 
system based on the representation problem". Technical Report CS-R9323, Centrum 
5 voor Wiskxmde en Informatica, April 1993) although it was already implicitly 
assumed in earlier cryptographic schemes. 

Definition of Decisional Diffie-Hellman Assumption - There is non probabilistic 
polynomial-time algorithm that distinguishes with non-negligible probability between 
10 the distributions D and R, where D = (g, ^, ^) with x, y, z Z and R = (g, g^, 

^.g'^)withx,y 

Ateniese et al gives a security proof of the ACJT group signature scheme by proving 
the following two theorems and one corollary. 

15 

Theorem 1 (Coalition-resistance). Under the strong RSA assumption, a group 
certificate fuj = (a^'b/^^' mod n, ej with Xi e A and d e F can be generated only by 
the group manager provided that the number K of certificates the group manager 
issues is polynomially bounded, 

20 

Theorem 2. Under the strong RSA assumption, the interactive protocol underlying the 
group signature scheme is a statistical zero-knowledge (honest-verifier) proof of 
knowledge of a membership certificate and a corresponding membership secret key, 

25 Corollary. In the random oracle model the ACJT group signature scheme is secure 
under the strong RSA and the decisional Diffie-Hellman assumption. 

Based on the security proof of the ACJT group signature scheme by Ateniese et al, we 
can argue that in the I'andom oracle model the group signature scheme with 
30 revocation evidence presented in the previous section is secure under the strong RSA 
assumption and the decisional Diffie-Hellman assumption. 
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Most security properties of. the general group signature scheme with revocation 
evidence (as set out above) follow straightforwardly from the above two theorems and 
one corollary. Note that all the properties of the ACJT group signature scheme are 
retained as the amoxmt of information revealed by (c, ^'i, .s'2, S3, S4, Ti, T2, T3) about the 
5 group member's secret and certificate is negligible (i.e., (c, ^-i, ^'2, S3, S4, T\, T2, T3) are 
statistically hiding commitments and the PjRr-protocol is statistical zero-knowledge). It 
remains to argue that the amount of information further revealed by disclosing C 
about the group member's secret and certificate is also negligible based on the 
decisional Diffie-Hellman assumption. 

10 

The specific group signature scheme with revocation evidence presented above is 
efficient, benefiting from the fact that the ACJT group signature scheme is very 
efficient. 

15 Communication: Our proposal is a signature scheme, not an interactive zero- 

knowledge proof scheme. To avoid replay attack, the verifier may chooses a 
unique message m and sends m with RevocationAgencyName (also chosen by 
the verifier) as a challenge to the signer, the signer then sends the signature 
back as a response. If the size of the RSA modulus n is 2048, which is 

20 recommended in the current TCG specification, the size of a signature is 

9xlog(/2) = 4.5k-bit. 

Computation: To make a signature, the signer needs nine modulo 
exponentiations. To verify a signature, the verifier needs five modulo 
25 exponentiations. 

The fact that TPM needs to use nine modulo exponentiations may introduce a time 
delay into the process of verifying a TPM's identity. This time delay can be 
minimised by pre-computing the TPM's group signature on randomly chosen data, 
30 and then using the challenge/response to prove that that signature was generated by 
the TPM. The challenge/response then requires two on-line modulo exponentiations 
by the TPM and seven (the original five plus an extra two) by the verifier. Using 
essentially the same idea as in the DP scheme, we let TPM create a group signature 
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using the above scheme on a randomly chosen message m' and a randomly chosen 
RevocationAgencyName' for a non-existent revocation agency. In that signature,/' = 
H(RevocationAgencyName^^ mod and C = (aff mod n. Later, during a real 
conrniunication with a challenger, the challenger sends information about a real 
5 revocation agency, RevocationAgencyName, and a jfresh message, m, as a challenge. 
Then the TPM creates real revocation evidence C = (off mod w, where / = 
H{RevocationAgencyNamef mod n. The TPM then creates a signature to show the 
knowledge and equality of two discrete logarithms of C and C with bases af and af 
respectively, by performing as follows: 

10 

1 . Randomly choose r ±{0, 1} 

2. Computec=/f(a|l/fJf||C||C1|(q/)'*modn ||(^/)'*mod /2||/7z). 

3. Compute s = r—ciz- 2^0 (in Z). 

4. Output (c, 5, Q. 

15 

To verify this signature, the challenger performs as follows: 

1. Check if C is in a relevant revocation list (for example, as maintained by a 
chosen revocation agency) which has a name - RevocationAgencyName, if 

20 yes reject the signature, otherwise carry on. 

2. Compute = H(a\\f\\f% C \\ 0\\ (afy-'^'' C'modw || (afy^"' C'modn \\ m). 

3. Accept the signature ifand only ifc-c', and 52 e ±{0, l}^(^+*>-^\ 

25 The approach to revocation in this second scheme is broadly similar to that set out in 
the first scheme. Again, the system involves four sets of entities: TPM manufacturers, 
TPMs, Revocation Agencies (RAs), and remote service providers RSPs. 

As before, we set out a scenario of applications: a TPM desires to communicate with 
30 an RSP for accessing a particular application purpose Pa. The RSP believes that an 
RA is trusted to maintain a revocation list of those TPMs which should not be allowed 
to access Pyj. The revocation list has a unique identity, RevocationAgencyName = 
P^||RA's identiyj|expiry date|| 
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In our group signature scheme with revocation evidence as specified above, the RA 
maintains such a revocation hst with the value C belong to those rogue TPMs and 
makes it available to RSPs. During the verification of a signature, each RSP first 
check if C is in the revocation list. Jfyes, RSP rejects this TPM. 

5 

Optionally, this RA can also play the role of a Certificate Authority (we call it 
RA/CA). In this case the RA/CA is the verifier in the scheme of group signatures with 
revocation evidence. The RA/CA has a traditional asymmetric key pair, Pra/ca axid 
jS'ra/ca, which are accessible by RSPs. After the verification of a TPM's group 

10 signature succeeds, the RA/CA certifies a randomly chosen identity with an 
asymmetric key pair, Ptpm and S^vm, by using Pra/ca and 5'ra/ca in a usual way (as 
the same as the private CA in the current version of TCG specification) and records C 
and the certificate of Ptpm- Optionally, the RA/CA records C with Ptpm for intemal 
access only and lists Ptpm in a publicly accessible revocation list. Note that this differs 

15 from the current version of TCG specification, in that this RA/CA is not given any 
TPM's endorsement key certificate. 

Li the same way as the current version of TCG specification, to access a service 
provided by Hie RSP, the TPM authenticates itself to the RSP with the certificate of 
20 Ptpm. The RSP verifies the certificate and also checks whether this certificate is in 
RA/CA's revocation list. 

Obviously, if a TPM is listed in iL4i's revocation list linked with the purpose Pa, the 
TPM can still access (1) the purpose Pb also managed by RA\i (2) the purpose Pa but 
25 managed by RA2\ and of course (3) the purpose Pb managed by RA2. 

It is of course possible to use multiple revocation lists. For example, if two revocation 
lists needed to be checked in one application: one based on RevocationAgencyName\ 
and the other based on RevocationAgencyName 2, the TPM will have to make two 
30 revocation evidences, one called C\ based on RevocationAgencyName\ and the other 
called C2 based on RevocationAgencyName2. 
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In this scheme, if a rogue TPM's endorsement key and key certificate have been 
pubhshed, any verifier can check whether a given group signature with revocation 
evidence is signed under the endorsement key and certificate. 

5 Using this scheme, there are a variety of different ways in which the issue of TPM 
ownership may be addressed. First of all, the use of an OEM (original equipment 
manufacturer) certificate will be considered - the OEM takes manufactured TPMs and 
integrates them into a computing platform host. There are at least three possible 
solutions for this, as follows. 

10 

Solutioii 1. hi this solution, the TPM manufacturer plays a role as Certificate Issuer 
and the OEM plays a role as a Revocation Agency. TPM has a special evidence 
related to a certain OEM, that is (employing the first version of evidence set out 
above) Eqem ^ (//(OEM-Name))^^. This evidence can be generated by CI (the TPM 
15 manufacturer) in the TPM setup process, or altematively generated by TPM. To 
convince the OEM that TPM is a genuine TPM, TPM sends the OEM a signature as 
set out above that has Eqem as E, After verifying the signature, the OEM issues a 
certificate on Eqem that could be a traditional PKI certificate. This solution does not 
offer the anonymity property, because Eqem is unique for TPM. 

20 

Solution 2. In this solution, both the TPM manufacturer and the OEM play a role as a 
CI in the scheme. TPM has one private endorsement key, z, and two related 
certificates (w, e) and (u\ e"). The first one is issued by the TPM manufacturer as 
described in Section 3, and the second one is issued by the OEM in the same way. The 

25 TPM manufacturer has a pubKc key {a, b, h, n) and TPM has related (w, e) (as 
described in Section 3). The OEM has a public key (a\ b\ g\ h\ n'). To convince the 
OEM of the correctness of TPM, TPM sends the OEM a second scheme signature 
under (z, e, u) on a message m = a'^ mod n' (which may concatenate with a challenge 
firom the OEM). After verifying the second scheme signature succeeds, the OEM 

30 issues (u\ e") to TPM, where w'^' = a'^b* mod n' holds. After that, TPM responds any 
challenge of requesting of the TPM manufacturer's certificate by sending a second 
scheme signature under (z, w, e) and (a, 6, g-, /z, tz), and responds any challenge 
requesting of the OEM's certificate by sending a second scheme signature imder (z, u\ 
and (a', 6', g\ A', This solution can offer anonymity if the second scheme 
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signatures are of different revocation evidences. The potential problem is that 
processing between the TPM and the OEM is cost. 

Solution 3. In this solution, the TPM manufacturer plays the same role as in the 
current version of TCG and the OEM plays a role as a CI in the second scheme. 
During the TPM manufacture, TPM obtains an ordinary endorsement key pair (as 
described in the existing TCG specification, but termed here pre-endorsement key 
pair). When the TPM manufacturer chips TPMs to the OEM, the TPM manufacturer 
sends a list of endorsement pubUc keys. The OEM creates a replaced endorsement 
key and certificate for each TPM by using Version 1 of the JOIN process discussed 
above. 

1. The OEM randomly chooses an exponent z ]1, 2^^] as TPMs endorsement 
private key, and computes v = a^. 

2. The OEM generates the endorsement key certificate {u, e) by selecting a 
random prime e [2^^ + 1, 2^^ + 2^^ ] and computing u = {ybf^^. 

3. The OEM encrypts (z, u, e) on TPMs pre-endorsement public key. 

4. The OEM publishes the encrypted (z, u, e) and a hash value of the pre- 
endorsement public key in a public domain. 

5. The OEM erases all of its knowledge of (z, u, e). 

6. When a TCG platform with TPM is received by a user, the platform 
downloads the encrypted (z, u, e) from the OEM's pubUc domain and TPM 
decrypts (z, u, e) by using the pre-endorsement private key. 

There are at least two possible solutions for taking ownership using the second 
scheme, both of which are based on the above OEM certificate solutions, and are as 
follows. 

Solution 1. It is suitable for both Solutions 1 and 2 above. The owner of the TCG 
platform uses (foEM= {H{OBM'Yizm€)f,EoEM, n) as a public ElGamal encryption key 
of TPM. The corresponding private ElGamal decryption key is TPMs endorsement 
private key z. The taking ownership protocol run between the owner and TPM is as 
follows: 

1. The owner chooses an ownership secret at random, s [1, 2^^^]. 
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2. The owner encrypts s under (foEu, Eqem, n) by using an ElGamal-encryption. 
To do this. The owner chooses a session secret at random, x [1, 2^^^], and 
computes U = foEiI'^^, and V'=^s^Eoem'' 

3. The owner sends {U, V) to TPM. 

5 4. TPM decrypts s by computing s = F* i7^. 

The decryption process requires one modular exponentiation and one modular 
multiplication. There is no new function for TPM needed. 

10 Solution 2. It is suitable for Solution 3 above. The owner of the TCG platform uses 
the pre-endorsement public key as an encryption key of TPM. The corresponding 
decryption key is TPMs pre-endorsement private key. The taking ownership protocol 
run between the owner and TPM is as the same as in the existing TCG specification. 
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CLAIMS 

1. A method of determining access to computational resources by means of a 
group signature scheme with revocation evidence, the method comprising: 

5 a certificate issuer holding a group secret key and providing a group pubUc 

key; 

a group member obtaining a membership secret and the certificate issuer 
providing a membership certificate for a group member in respect of the membership 
secret; 

10 the group member demonstrating that it possesses a valid membership secret 

and a valid membership certificate to a verifier without revealing the membership 
secret or the membership certificate to the verifier by providing a signature, and 
providing revocation evidence firom its membership secret and a revocation 
parameter; 

15 the verifier determining firom the signature and firom the revocation evidence 

that the group member possesses a valid membership secret and a valid membership 
certificate. 

2. A method as claimed in claim 1, wherein the group member generates the 
20 membership secret. 

3. A method as claimed in claim 1, wherein the certificate issuer generates the 
membership secret and the membership certificate. 

25 4. A method as claimed in claim 1, wherein the group member is a trusted 
computing device and the certificate issuer is a manufacturer of the trusted computing 
device. 

5. A method as claimed in claim 1, wherein revocation evidence is compared by 
30 the verifier with a revocation list held by a revocation agency associated with the 

revocation parameter. 

6. A method as claimed in claim 1, wherein revocation evidence is compared by 
the verifier with a revocation list held by the verifier. 
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7. A method of demonstrating a trust status by a member of a group signature 
scheme which has a group pubUc key, the method comprising: 

the group member obtaining a membership secret and receiving from a 
5 certificate issuer a membership certificate for a group member in respect of the 
membership secret; 

the group member demonstrating that it possesses a valid membership secret 
and a vaUd membership certificate to a verifier without revealing the membership 
secret or the membership certificate to the verifier by providing a signature, and 
10 providing revocation evidence from its membership secret and a revocation 
parameter. 

8. A method as claimed in claim 7, wherein the revocation evidence E is of the 
form £' where f is a one-way ftinction performed on the revocation parameter, 

1 5 and z is the membership secret. 

9. A method as claimed in claim 7, wherein at least a part of the signature is 
precomputed by the group member before it is requested by a verifier. 

20 10. A method as claimed in claim 7, wherein at least a part of the revocation 
evidence is precomputed by the group member before it is requested by a verifier. 

11. A method of verifying a trust status of a member of a group signature scheme 
which has a group public key, the method comprising: 

25 the verifier receives from a group member a signature generated from a 

membership secret and a membership certificate of the group member, and receives 
revocation evidence provided by the group member from its membership secret and a 
revocation parameter; and 

the verifier determining from the signature and from the revocation evidence 

30 that the group member possesses a valid membership secret and a valid membership 
certificate. 

12. A method as claimed in claim 11, wherein the verifier determining that the 
group member possesses a valid membership secret and a valid membership 
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certificate comprises checking the revocation evidence against one or more revocation 
Ksts, determining that the revocation evidence and the signature are consistent, and 
that the signature is consistent v^ith formation from a properly formed membership 
secret and a properly formed membership certificate. 

5 

13. A method as claimed in claim 12, wherein at least one of the one or more 
revocation lists is held by a revocation agency. 

14. A method as claimed in claim 12, wherein at least one of the one or more 
10 revocation lists is held by the verifier. 

15. Trusted computing apparatus comprising a processor and a memory containing 
a membership secret and a membership certificate issued on the membership secret by 
a certificate issuer for a group signature scheme having a group public key, the trusted 

15 computing apparatus being adapted to demonstrate that it possesses a valid 
membership secret and a valid membership certificate to a verifier without revealing 
the membership secret or the membership certificate to the verifier by providing a 
signature, and to provide revocation evidence firom its membership secret, its 
membership certificate, the group public key and a revocation parameter. 

20 

16. A method by which a first party can prove to a second party that it possesses a 
secret legitimately provided by a third party, comprising the steps of: 

the third party providing to the first party a first secret m, and a second secret c 
calculated according to the relation c = {ti?rf^ + t2Y' mod n from the first secret, where 
25 ?2 is a RSA modulus, e\ and e2 are RSA public exponents, and ti and t2 are randomly 
chosen integers, whereby d\ is an RSA private exponent corresponding to 

the second party obtaining from the third party w, eu ^2, h and tzi 

in order to prove to the second party that it has a fibrst secret m and a second 
secret c formed according to the relation, the first party provides the second party with 
30 a first plurality of results of a one-way fimction using the first secret and a second 
plurality of results of a one-way fimction using the second secret; 

whereby the second party compares the first plurality of results with results of 
a one-way fimction using e\ and the second plurality of results with results of a one- 
way fimction using 02, and thereby verifying that the first party has a first secret m 
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and a second secret c formed according to the relation without receiving either the 
first secret m or the second secret c. 



17. A method as claimed in claim 16, wherein the first party provides the first 
5 plurality of results and the second plurality results in a digitally signed mathematical 
structure, aad wherein the second party checks the validity of the digital signature and 
if valid, evaluates the mathematical structure in the process of verifying that the first 
party has a first secret m and a second secret c formed according to the relation. 

10 18. A method as claimed in claim 16, wherein the first party provides the first 
plurality of results and the second plurality of results interactively to the second party 
to provide a zero-knowledge proof that the first party has a first secret m and a second 
secret c formed according to the relation. 

15 19. A method as claimed in claim 16, wherein the first party comprises trusted 
computing apparatus, the second party controls access to a service, and the third party 
is a manufacturer or guarantor of the trusted status of the trusted computing apparatus. 

20. Trusted computing apparatus comprising a processor and a memory containing 
20 a first secret m, and a second secret c calculated according to the relation c = {t\nf'' + 
fe/' mod n firom the first secret, where w is a RSA modulus, e\ and €2 are RSA pubUc 
exponents, and t\ and tz are randomly chosen integers, whereby is an RSA private 
exponent corresponding to ei, wherein the processor is programmed to prove to an 
other party that it possesses a first secret m and a second secret c formed according to 
25 the relation without revealing either the first secret m or the second secret c, by 
providing the other party with a first plurality of results of a one-way function using 
the first secret and a second plurality of results of a one-way function using the second 
secret. 

30 21. A method of controlling access of a first party to a service provided by a 
second party, wherein the first party is adapted to prove to another party that it 
possesses a secret legitimately provided by a third party without revealing the secret, 
comprising the steps of: 
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the first party proving and the fourth party verifying that the first party 
possesses a secret legitimately provided by the third party without the secret being 
revealed to the fourth party, 

the fourth party issuing a certificate to the first party and associating with the 
5 certificate an identifier of the step of verifying that the first party possesses a secret 
legitimately provided by the third party that would be regenerated in a later step of 
verifying that a party possesses that secret, 

the fourth party maintains certificate validity information, whereby when the 
first party attempts to obtain access to the service, it provides the certificate issued by 
10 the fourth party to the second party, and the second party determines from certificate 
validity information provided by the fourth party whether the certificate is valid 
before providing access to the service. 

22. A method as claimed in claim 21, wherein the fourth party is adapted to 
15 revoke the certificate on receiving an indication that the certificate has been used in an 
invaUd manner, and is adapted not to issue any further certificate to a first party if the 
process of verifying that the first party possesses a secret legitimately provided by the 
third party generates the identifier associated with the revoked certificate. 

20 23. A method as claimed in claim 21 or claim 22, wherein the certificate 
comprises identification of the fourth party and identification of a purpose for which 
the certificate may be used. 
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